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Crater et al.. Object-oriented programmable industrial controller w'th distributed 
interface architecture, filed May 29, 1998 (hereinafter "Crater"). Applicant again 
requested an interview, which Examiner graciously granted. The interview was held on 
Feb. 6 with Examiners Bashore and Stevens. The basis for the interview was a written 
Argument which was faxed to Examiner Stevens on 2/3/2006. The Argument traversed 
the rejections. What is presented in the following is an expanded version of the 
Argument. 

Traversal 

The following Traversal will first present an overview of an embodiment of what 
Applicant is claiming, then a discussion of claim 1. That will be followed by an 
overview of the disclosures of the Hirsch and Crater references, and then a demonstration 
that the claims' limitations include features of the embodiment which are not present in 
the references. The traversal will finally discuss the dependent claims. 

Overview of an embodiment of what Applicant is claiming 

What follows are sections from Applicants' Specification as filed which provide an 
overview of an embodiment of what Applicant is claiming. Page and line numbers are 
from the Substitute Specification filed on 1/20/05: 

In broad terms, process control system 801 works by making records of 
processes that are being controlled in a table in database system 825 and 
using predefined queries that are stored in a table database system 825 to 
repeatedly query the table and perform activities that are predefmed for 
the query on the resuh set of records returned by the query. The repeated 
queries are executed automatically by system 801. The predefined and 
automatically executed queries are termed herein administrative queries. 
An activity is made up of a number of predefined actions, and when the 
activity is performed, system 801 executes its actions. The activities to 
be performed by an administrative query, as well as an activity's actions, 
are also defined by entries in tables in the database system, and log tables 
in the database system determine the state of a process record returned by 
the administrative query with regard to that execution of the administrative 
query. When an execution of a query returns a process record, system 
801 uses the state information to determine what activity is to be 
performed with regard to the process record. (Page 8, lines 3-17) 
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. . . most actions involve changing one or more values of fields in the PR 
record upon which the action is performed. Such changes of course affect 
what queries will return the PR record, and thus move the PR record 
through the stages of a process that the PR record is an instance of The 
manner in which the types of certain fields in the PR records are defined 
greatly increases the ease and safety with which actions may be defined 
and modified. Many of these types are defined by system 801; others may 
be defined by users. In both cases, the types are defined using the 
facilities which database system 825 provides for user-defined types, 
(page 63, lines 14-22) 

FIG. 13 shows the graphical user interface for defining an AA set value 
action in system 801. These actions set fields in PR records whose values 
neither represent times or dates nor represent persons or roles. The fields' 
types may be defined by system 801 or users of system 801, but the values 
for each type must constitute an ordered set. An example of such a field is 
a priority field for which the values may be {low, normal, emergency}. 
Window 1301 contains a list of fields in PR records in system 801 that 
may be set by AA set value actions. The entry 1302 for each field has 
the field's name (1303), its type (1305), i.e., whether its values may belong 
to a single type or to more than one type, the operation to be performed on 
the field's value (1307), which is one of set, increment, or clear, as shown 
by the drop-down menu at 1311, and the value to which the field is to be 
set (1309), if the set operation is specified. Row 1302 thus specifies the 
set value action as setting the value of the field priority to Emergency. 
The detail of window 1301 at 1310 shows how the user may see the 
available operations by clicking on field 1307 in entry 1302 to get drop- 
down menu 1311, fi-om which the user can select the desired operation. 
The detail at 1313 shows the window showing the possible values of the 
field priority which appears when the user clicks on field 1309 in row 
1302. The user may select one of the values in the window. Creation or 
modification of an AA_set_value action in window 1301 of course results 
in the creation or modification of a record in AA set_values table 859. 
As shown by this interface, system 801 separates definition of PR records 
fi-om definition of operations on PR records. 

FIG. 13 also shows a number of general characteristics of the windows 
that are used to defme actions in a preferred embodiment. There is a 
window for each kind of action, and each window contains a table which 
has an entry for every field in any of the PR records defined in system 801 
which can be set by the kind of action that the window defines. An entry 
has two parts: the first part, 1303, is a field which identifies the field in 
the PR record which will be affected by the action. The second part 1306 
is one or more fields that define the action to be taken on the field 
identified by field 1303. What fields are in 1306 and how they define the 
action depend on the kind of action, or put another way, on the type of the 
values which field 1303 may contain, (p. 67, line 5-p. 68, line 1 1) 
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Several features of the embodiment of the invention as described in the above overview 
are particularly relevant to the present discussion: 

■ A PR record represents the current state of a process being monitored. The process's 
current state is specified by values in fields in the PR records 

■ The embodiment automatically performs administrative queries on PR records that 
look for PR records having particular states as indicated by particular values in the 
record's fields. 

■ An administrative query may have an action associated with it that sets the value of a 
field in PR records returned by the administrative query. An administrative query 
that detects PR records having a particular state can thus perform an action that 
moves the PR record to another state. 

■ The embodiment provides a GUI which permits a user to define an action that sets 
the value of a field in a PR record and associate the action with an administrative 
query. 

As can be seen from the foregoing, the database system in Applicants' embodiment of the 
invention is not merely a passive collection of information about a process. Instead, the 
PR record represents the process and moves through a succession of states as the process 
moves through the succession of states. One of the mechanisms for moving the PR 
record through the succession of states is administrative queries with associated actions. 
The GUI permits users to define actions and associate them with administrative queries. 

The embodiment and Applicant's claim 1 

Applicants' application has a single independent claim, claim 1, which as amended in the 
Submission that accompanied the RCE, reads as follows: 

1- A graphical user interface for specifying an action which modifies a 
value of a field of a record stored in a memory device, the action, once 
specified, being thereafter automatically performed when a query with 
which the action is associated returns the record, the query being executed 
on a processor that has access to the memory device and interacts with the 
graphical user interface, and 
the graphical user interface comprising: 

a window containing a table wherein the field of the record has an 
entry that is selectable by the user, the entry including 
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a first field of the entry that identifies the field of the record 
to be modified by the action; and 

one or more action fields of the entry that, when the user 
has selected the entry, the user may set to specify the action. 

In this claim, lines 1-4 clearly set forth the relationship in the embodiment between the 
action, the query, and the records returned by the query described above and lines 7-12 
set forth the user interface that is used to specify the action. Since terms such as "field of 
the record" and "action" which appear in the portion of the claim that describes the GUI 
are defined in the preamble, the preamble must be taken to limit the body of the claim. 

The disclosures ofHirsch and Crater 

Hirsch and Crater both disclose databases that contain information which is used to 
control manufacturing processes. An important distinction between the databases of 
Hirsch and Crater and the database in the embodiment of Applicant's invention is that the 
databases ofHirsch and Crater are passive collections of information The information in 
the databases is used to produce programs that control the actual processes, but the 
database does not change as the state of the process changes. Thus, Hirsch and Crater 
provide programming GUIs which the user may use to defme objects in the database, but 
in neither case do they have a GUI which permits the user to specify an action, which, 
"once specified, [is] thereafter automatically performed when a query with which the 
action is associated returns the record" (claim 1, lines 2-4). 



The disclosure of Hirsch 

Hirsch 's disclosure is well-described by its Abstract: 

The present invention provides a method and system, for use with a 
computer integrated m2magement system, to classify and serve as the data 
and information repository for a process or product specification and to 
classify groups of process resources. The Process Type method provides 
information to describe the outcome of a process. The organization 
describing a Process Type includes three basic components. The first 
component is an action. The action cony)onent describes what is to be 
done by the process. The second component is material. The material 
component describes the element upon which or with which the action 
described by the action component is performed. The third component is 
technology. The technology component describes the resource which 
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performs the action described by the action component with or upon the 
material described by the material component. The resuhing Process Type 
is then used to control a process or the generation of a product to achieve a 
desired result. 

As set forth in col. 2, lines 23-27, 

Data describing the managed set of manufacturing components is stored in 
an information repository and made available to all Computer Integrated 
Manufacturing (CIM) software applications and embedded equipment 
control software. Thus, it is another object of the present invention to 
ensure consistent representation of relationships and dependencies 
between the managed manufacturing components. 

There is clearly nothing in Hirsch which works anything like the database of the preferred 
embodiment. In his rejection of claim 1, Examiner cites FIGs. 3 and 10, but what is 
shown in these figures is GUIs that are provided to define the contents of the repository. 
In particular, FIG. 3 is the GUI for creating, editing, deleting or reviewing a process type 
in the repository. FIG. 10 is the GUI for creating, editing, or deleting a plan for sampling 
a product during the process that makes it As set forth at col. 1 1, lines 33-35, the data 
sampling plan "includes the parameters necessary for the equipment to perform the 
measurements". The GUI of FIG. 10 thus specifies an action which is carried out by the 
equipment doing the processing; it does not specify an action which is carried out on 
records in the repository, as required for Applicants' claim 1. 

Tlie disclosure of Crater 

Crater discloses an object-oriented approach to process control programs. FIG. 1 shows a 
controller 100 for use with a machine; included in the controller is control block 140, 
which contains "computer-executable instructions for actually operating controlled 
equipment via I/O modules 120. (col. 8, lines 36-38). A detailed view of control block 
140 is provided by FIG. 3, described beginning at col. 13, line 22. Object manager and 
database 315 contains objects which specify actions to be performed by the controlled 
equipment or displays on Web browsers. The information in the objects may be 
compiled by compiler 320 to produce code for run-time control program 325 that is 
executed directly by devices 330, 335, 160, and 170, or these devices may themselves 
interpret the information in the objects in object manager 315. 
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To program controller 100, the user employs programming interface 300. Programming 
interface 300 provides a GUI for specifying objects in object manager 315. The GUI is 
shown in FIGs. 4A-5C. FIG. 4A, which is specifically cited by Examiner in his rejection 
and which is explained beginning at col. 16, line 19, shows the properties currently 
associated with the CAPPER object in object manager 315. This object represents the 
capper in a bottling line The capper's properties include its name, shown at 410, and a 
set of "parts", shown at 415. As explained at lines 38-44, the parts are input signals 
specifying that the capper be raised or lowered and output signals indicating whether the 
capper is up or down. Thus, like the GUI of Hirsch's FIG. 10, the GUI of Crater's FIG. 
4A specifies an action which is carried out by the equipment doing the processing; it 
does not specify an action which is carried out on records in object manager 315, as 
would be required if Hirsch were to read onto Applicants' claim 1. 

Patentability of Applicants ' claims over the references 
Patentability of claim 1 

Because Hirsch and Crater neither disclose singly nor in combination claim I's action 
that is associated with a query, that modifies a value of a field of a record, and that is 
automatically performed when the query returns the record, they cannot either singly or 
in combination disclose a graphical user interface for specifying such an action. Since 
the combined references do not disclose all of the elements of claim 1, Examiner has not 
made his prima facie case of obviousness and his rejection of claim 1 is without basis. 
Claim 1 is the only independent claim in the application; consequently, if claim 1 is 
patentable, so are ail of the other claims in the application. 

Patentability of the dependent claims in their own rights over the references 
Beginning with claims 2 and 3, these claims further specify the types of the identified 
field's values and the effect of the types on the interface. Since there is nothing 
corresponding to claim 1 's field of a record that may be returned by a query in Hirsch or 
Crater, claims 2 and 3 are patentable in their own rights over Hirsch and Crater separately 
or in combination. Claims 4-19 all have to do with the actions that may be specified in 
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the action fields of the interface. These actions are of course performed on the identified 
fields, and since there is nothing in Hirsch or Crater about actions that are automatically 
performed on a field of a record when the record is returned by a query, the claims 4-19 
are also patentable in their own rights over Hirsch and Crater separately or in 
combination. 



ConcliDsion 

Applicant has traversed all of Examiner's rejections of the claims and has therefore been 
completely responsive to the Office action of 11/8/2005, as required by 37 C.F.R. 
1.111(b). ^^plicant consequently respectfully requests that Examiner continue with his 
examination as provided by 37 C.F.R. 1.11 1(a)(1). No fees are believed to be required by 
way of this response. Should any be, please charge them to Deposit Account Number 
501315 

Applicants' attorney would like to take this opportunity to again thank Examiners 
Bashore and Stevens for the courtesy which they extended to him during the interview of 
2/6/2006. 

Respectfully submitted, 

Attorney of record, 
Gordon E. Nelson 
57 Central St., P.O. Box 782 
Rowley, MA, 01969, 
Registration number 30,093 
Voice: (978)948-7632 
Fax: (866)-723-0359 
2/6/06 

Date 

Certificate of Transmission 

I hereby certify that this correspondence is being facsimile transmitted to the United 

States Patent and Trademark Office, Fax No. 571-273-8300 on 2/6/06 

(Date) 

Gordon E, Nelson, #30,093 
(Signature) 
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